System and method for managing distributed media files

ABSTRACT

There is disclosed a media file distribution system and method. An asset management and delivery system and method for the distribution of digital files and data is provided. There are two major functions, with sub-functions within each. The system first serves as a fully automated management system for a company involved in video/file distribution, such as in video on demand (VOD) or other digital file industries. The system can ingest, prepare, schedule, transmit, track and report on any aspect of the business chain. Secondly, it also serves as a product for both content providers and recipients to be able to view, manage and run their entire content offering remotely from anywhere through the Internet.

CROSS-REFERENCE TO RELATED APPLICATION(S)

This is a divisional of U.S. application Ser. No. 11/182,724, filed onJul. 15, 2005. The contents of which are incorporated herein byreference.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialthat is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent files or records, but otherwise reserves all copyrightrights whatsoever.

FIELD OF THE INVENTION

This invention relates generally to a media file distribution system andmethod, and more particularly, to a system and methodology that providesend-to-end management of distribution of a media asset.

BACKGROUND OF THE INVENTION

The task of distributing media files from network content providers torecipient media front-end customers, such as cable providers, and thelike (collectively called “recipient sites” herein), has become acomplex process. This is mainly due to competing interests in fileformats, transmission protocols, processing requirements, program guideentry format, and various other parameters configured according todifferent standards as amongst the various content and service providersinvolved in the distribution process. Accordingly, inordinate amounts oftime are now spent converting formats in order for content providers,distributors, and the recipient site customers to manipulate and modifymedia files throughout the distribution process in order to comply withtheir diverse system requirements.

The typical media file is a media/digital file for use in videoplayback, gaming, or any other digital medium. Such a file is sent oversatellite, the Internet, or other network, to those involved indistribution and final presentation to the public from the front end orto the recipient site customers. A data control file arrives with themedia file which data file must be constantly modified with eachconversion to a new system. Current systems typically transmit thecontrol file in one of three ways. The first is to target a uniquemetadata control file to each receiving site, thereby requiring N numberof files for N sites. The second way is to send one generalized file toall receiving sites and then have a site-specific transformation occurat each site dictated by information stored at each site that istriggered by the general information in the control file. A third way tois to send one control file to all receiving sites and then to requireeach site to process the one format in that control file to be used, butthis approach precludes any site specificity. In each of theseapproaches limitations are necessarily imposed on, for example, theamount and types of different properties that can be applied to aningested media file, and its distribution characteristics. Further,multiple systems are required, increasing the working time andlikelihood of errors, as well as causing synchronization issues. Forexample, these approaches can be characterized by the frequent failureof in-bound value readers to pass data that is expected by site-specifictransform mechanisms. Users in these media distribution system are thenforced to manually adjust all of the media assets within the scheduleaccordingly, while continuing to monitor any additional changes thatmight be introduced by any of the entities that play a role in, or thatotherwise involved in the overall media distribution system.

In summary, no current system performs end-to-end automated ingestionand monitoring of media assets.

BRIEF SUMMARY OF THE INVENTION

Briefly, and in general terms, the claimed invention resolves theaforementioned and other problems by providing a media file distributiondata system and method. A single media file is used for distribution totwo or more recipient sites. A first recipient site has first parameterrequirements for processing the media file, and a second recipient sitehas second parameter requirements for processing the media file that aredifferent from the first parameter requirements. A first set ofparameters is included in the media file that meets the first parameterrequirements. Further, a second set of parameters is included in themedia file that meets the second parameter requirements. In this regard,the first set of parameters is for use during distribution to the firstrecipient site, and the second set of parameters is for use duringdistribution to the second recipient site.

In accordance with another aspect of a system and method for automatedprocessing of a media file for distribution. In the distribution systemand method, a media file is received for distribution. The media filehas an asset type, and is validated according to one or morerequirements according to the asset type. As a result of validating, oneor more errors are produced. These errors are corrected by applying arules application to the media file. The media file is then distributed.

In accordance with another aspect of a system and method for automatedprocessing of a media file for distribution to a recipient site. A mediafile is provided for distribution. The multi-media file is processed toproduce data parameters for distribution. A receiving status of therecipient site is checked. One or more of the data parameters arechanged according to the receiving status of the recipient site. Forexample, according to one embodiment, the data parameters are changedaccording to a set or rules defined in a contract with the recipientsite. The media file is then distributed to the recipient site accordingto the data parameters. Further, an interface is provided so as to allowan operator of the recipient site to view status information regardingdistribution of the media file.

In accordance with another aspect of a preferred embodiment, the claimedinvention is a system and method for optimizing distribution of a mediafile to a plurality of recipient sites. A receive status of a firstrecipient site is checked, thereby producing a first status checkresult. A receive status of a second recipient site is checked, therebyproducing a second status check result. Based on the first status checkresult and the second status check result, a rules engine is applied todetermine a priority for distribution to the first recipient siterespective of the second recipient site. The media file is thendistributed to the first recipient site and the second recipient siteaccording to the determined priority.

In accordance with another aspect of a preferred embodiment, the claimedinvention is a system and method for providing connectivity in a mediafile distribution system. The system includes a data store, a portion ofwhich is for storing a media file received from a content provider. Adatabase in the data store contains editable parameters for distributionto the recipient site. An interface to the database allows the contentprovider to edit the parameters. The interface further allows therecipient site to edit the parameters. A distribution “sub system” isconfigured for distributing the media file according to the parameters.

In accordance with another aspect of a preferred embodiment, the claimedinvention is a system and method for providing interactive program guideentry for a media file. A distribution hub stores a media file receivedfrom a content provider for distribution to a recipient site. Aninterface to the distribution hub allows editing of program guide datafor the media file. The interface stores the program guide data to themedia file. The interface further allows the content provider to viewthe program guide data for the media file. In one embodiment, theinterface further allows the content provider to edit the program guidedata, and to set parameters regarding editing of the program guide databy the recipient site.

In accordance with another aspect of a preferred embodiment, the claimedinvention is a system and method for providing a multi-port catcher. Thesystem includes a computer, a data store, and a network connection forconnecting the computer to a network. In one aspect of this embodiment,a partition application is executed on the computer to partition thecomputer into multiple partitions. A catcher application executes ineach partition. Each catcher application is capable of receiving aseparate media file over the network connection, simultaneously. Eachmedia file is stored in the data store. The system may use a pluralityof catcher applications, wherein, for example, a first partitionexecutes a first catcher application, and a second partition executes asecond catcher application. Therefore, the first catcher application canuse a different protocol than the second catcher application. In thissense, the partition application is configured to divide processing of aprocessor of the computer into virtual computers, such that each of themedia files are received by a partition executing in one of the virtualcomputers.

In one embodiment, one of the partitions is configured as a contentprovider itself, such that one or more of the media files can beprovided internally from the data store into the catcher without using aseparate computer to provide the one or more media files to the catcher.In this or other embodiments, one of the partitions is furtherconfigured as a gateway computer to provide gateway processing for eachof the other partitions.

In accordance with another aspect of a preferred embodiment, the claimedinvention is a system and method for administrating a contract fordistribution of a media file. A media file is received from a contentprovider, after which, contract parameter data is entered into the mediafile according to a contract between the content provider and arecipient site. Metadata is calculated for the media file based on thecontract parameter data. The media file is then distributed to therecipient site. In one embodiment, by way of example, and not bylimitation, the contract data includes price limitations that therecipient site can charge for viewing of the media file. As anotherexample, and not by limitation, the contract data includes timelimitations defining limitations regarding a time that the recipientsite can present the media file.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is network block data flow diagram illustrating components andsteps performed in a media file distribution system and method accordingto one embodiment;

FIG. 2 is a screen shot from an example interface for a content providerfor the system and method of FIG. 1;

FIG. 3 is a screen shot from an example interface for a contentrecipient site for the system and method of FIG. 1;

FIG. 4 is a block diagram illustrating field portions of a media fileformatted according to one embodiment;

FIG. 5 is a network block data flow diagram illustrating components andmethod steps in a transmission “sub system” and method according to theembodiment illustrated in FIG. 1;

FIG. 6 is a network block data flow diagram illustrating data flowbetween content providers, catchers, and a data store, according to oneembodiment;

FIG. 7 is a screen shot from an example asset tracking interface for acontent provider for the system and method of FIG. 1;

FIG. 8 is a screen shot from an example package profile editinginterface for a content provider for the system and method of FIG. 1;

FIG. 9 is a screen shot from an example interactive program guideediting interface for a recipient site for the system and method of FIG.1;

FIG. 10 is another screen shot from an example interactive program guideediting interface for a recipient site for the system and method of FIG.1;

FIG. 11 is data flow diagram illustrating steps performed by a contractmanager “sub system” according to one embodiment; and

FIG. 12 is data flow diagram illustrating the flow of data for applyinga contract template to create contract parameters for a media fileaccording to one embodiment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Referring now to the drawings, wherein like reference numerals denotelike or corresponding parts throughout the drawings and, moreparticularly to FIGS. 1-12, there is shown one embodiment of a mediafile distribution system in accordance with the claimed invention.Specifically, the claimed invention provides an asset management anddelivery system for the distribution of digital files and data. Thesystem has two major functions, with sub-functions within each. Thesystem first serves as a fully automated management system for a companyinvolved in video/file distribution, such as in video on demand (VOD) orother digital file industries. The system can ingest, prepare, schedule,transmit, track and report on any aspect of the business chain.Secondly, it also serves as a product for both content providers andrecipient sites to be able to view, manage and run their entire contentoffering remotely from anywhere through the internet.

There are three typical users for the system. One is any company orindividual distributing digital media and associated information. Theywould typically use the system to automate distribution. Another user isa content provider in the digital media space. This entity can use thesystem to enter assets, track them at their destination, and receivereports on them. Another typical user is a receiving client or customerwho can use the system to view and alter their assets, and schedule,monitor or change their receiving equipment setup or architecture. Witheach “sub module” described as follows, the usefulness of the claimedsystem will become apparent to those skilled in the art.

In one embodiment, the claimed invention has the ability to ingest mediafiles and data, prepare them for transmission across the media industry,localize all the applicable data by customer and track, and reconcilethe distribution of that data, all within the same system.

With reference to FIG. 1, the structure of the system 100 includes aseries of components and functions. The first component is for assetingestion into the system. Digital files and associated data are enteredinto the system in a variety of ways such as through standard filetransfer protocol (FTP) or satellite transmission over a satellite linksuch as an outgoing satellite link 190 used for distribution. This datais then scanned for compliance to formats, quality, and expectedparameter values, process block 150. The expected parameter values thatare specific to each content provider are stored in provider tables 170,wherein the system compares the stored provider specific expectedparameter values to those received with each media asset. Media packagespecific expected parameters are stored in package tables 504, whereinthe system further compares those package specific expected parametersto the parameter values received with each media asset. To the extentthat any parameters need to be added or are missing, the systemcalculates those parameter values based on data stored in metadatatables 516. Such calculated metadata may be archived into an archivetable 176 for later review, or backup.

The digital files are then transformed into customer-specific formats, aprocess that begins at process block 152. In a package determinationprocess, the metadata of the media file is processed and added to thefile. The system 100 has the unique ability to be ingestion-formatagnostic, meaning that, however the content provider would like to enterfiles into the system, it can recognize the interface typeautomatically, and perform the appropriate protocol to ingest the file,process block 154. The data is then queued, process block 156, andscheduled for transmission over any medium (e.g. over the satellite link190, the Internet, and such), and prepared for that transmission. Beforedistribution, reporting information regarding each file to betransmitted is stored in transformed asset tables 159.

The actual distribution is then performed, process block 158. In theexample of FIG. 1 transmission of the media files 190 occurs viasatellite 190 through a communication server 160, to docking stations186 at the recipient site head ends. After distribution, the media filesare tracked, reconciled, and reported on, through a network managementsystem (NMS) 188. This comprehensive approach enables any one area ofthe system 100 to affect properties and functionality of any or all ofthe other components, and to optimize the entire end-to-end performanceof the system.

The system 100 enables users to author metadata (the control andinformation file for digital files in the video on demand environment)for video assets and export them for use. In one embodiment, themetadata affects the transmission of the media assets from contentproviders to recipient sites, such as multiple system operators (MSOs)receiving video-on-demand content. The system also performs gatewayfunctionality, which in the context of one embodiment, includesaggregation of files from multiple transmission systems through onepoint of entry. This comprehensive control gives the system the uniquecapability of allowing any and all formerly disparate or disconnectedfunctions of the distribution chain to interact with each other, therebyoptimizing all functions and capabilities of the entire network andallowing file handling based on data from the entire distribution system100.

In one sense, the system 100 functions as an automated file recipientsystem for content distributors to aggregate data and digital mediafiles. These media files are ingested into the system 100 through anautomated ingest subsystem, processing block 104. Once received themedia files are manipulated and scheduled for distribution to therecipient sites or customers of the content providers, such as localcable companies and the like. The system 100 also allows those samecontent providers to author the parameter data for their media filesdirectly through a provider remote interface sever (PRI) 120. In oneembodiment, the parameter data is edited directly into the system orprovided pre-formed into a folder on the network in order to beautomatically ingested with the media file. Once entered, this parameterdata is immediately transformed into data specific to the contentrecipient sites that will receive it later.

In another sense, the system 100 provides the ability for all thecustomers to view the media file and status data through the Internet atall points in the distribution chain, using an affiliate remoteinterface server (ARI) 122. The customers can log into the system overthe web through the ARI 122, and view relevant media file data, not onlyin the original form in which it was entered, but also in the form aftertransformation in the system. For example, with respect to program guidedata, parameter data can be viewed in a form, as it will appear whenrecipients display it to their cable or media viewers.

In one example, a content provider logs into the system to view theproperties of their media file that are provided to a recipient, forexample, a cable MSO. These properties include the price for viewing themedia file from the affiliate, times or available times for viewing themedia file, overrides to certain values found in the control metadata,such as provider or distributor information, and financial information,such as revenue splits. The providers can also view the interface thecontent recipients display to their viewers. FIG. 2 shows an examplescreen shot from PRI 120.

The media recipients can log in through the ARI 122, and can also reviewcontent available in the system. Through the ARI 122, media recipientscan sign up to receive content, thereby added the media recipient todistribution lists for media files. The recipients can also view themedia file content before making decision on which media files toreceive. An example screen from the ARI 122 used to perform thesefunctions is shown in FIG. 3.

In one embodiment, an example scenario with respect to ingestion andprocessing of a media file follows. At a network connection 106 in FIG.1, a file first arrives at an ingestion server 108 without any manualintervention. The network connection 106 preferably comprises any highspeed internet connection, such as a T1, T2 or high-end DSL connection.The ingestion server 108 reads the file's parameters, which are enteredby the content provider, and the type of file is determined.

After initially receiving the media file, in one embodiment, a mediafile manager 512 manages processing of the file. For example, the mediamanager 512 can determine that the parameters of a media file require itto move immediately to the front of a satellite distribution queue,process block 156. The parameters read are a part of the correspondingmetadata received with the file from the content provider. Certainfields are present in that data, such as the content tier, which tellsthe system the file type, which defines processing rules that areapplied to the file in process block 154. In this step, parametersrelated to one or more contracts between the recipient and the contentprovider are added to the aggregate file, as described below withrespect to FIGS. 11-12. The contract parameters may be determined fromcontract data in financial/contract tables 172. At that time, financialreports regarding the file are calculated and stored in a financialreporting module 174.

Since, in this example, the parameters indicate that immediateprocessing is necessary, the file is then moved across an internalsystem 100, transmitted immediately, and reported on immediately so thatall the recipient sites have it as quickly as possible.

In another example, a media file that arrives late automaticallytriggers a change in any previously scheduled transmission date withinits parameters. This change flows through the entire system whereparameters for that media file are kept. The system changes theavailability date for that media file within its associated metadata.That change affects any financial projections, which are alsoautomatically figured from the same data.

Further in another example, a change in receiving status/capability ofone of the remote recipient sites triggers a change in the expectedtransmission schedule should that recipient site be part of an upcomingscheduled distribution. This status affects the transmission order andtimeline, and the changes populate back through the system. For example,should a number of recipient sites be unable to receive the media fileat the time they are intended to receive transmission from thedistribution, the system automatically changes the schedule fordistribution according to one or more set of rules. The schedule may bechanged to the next immediate distribution, or a distribution thatoccurs the next hour or later to allow those sites change to a favorablereceiving status. With this feature of automated transmission, timeupdating has the effect of optimizing the use of transmission making thesystem more efficient.

If there is an automatic parameter change, such as in the examplesregarding time of transmission described above, other subsystems in theclaimed system, such as a contract management subsystem, determine rulesfor proceeding and adjust data surrounding the media file accordingly.For example, the contract management rules might require the media fileto be sent to a recipient site regardless of the receiving status of therecipient site. Alternatively, a rule may define the latest date that amedia file may be sent. In that case, similarly, if the latest send-dateindicates that the media file cannot be delayed any longer, the mediafile is required to be sent regardless of the receiving status of thetarget recipient site in the distribution. Content providers viewingdata in the system see these changes in real time and related reportdata is also changed applicably.

Changes can also be made manually. If parameters for a media file arechanged by one of the content providers or recipient sites through thePRI 120 or the ARI 122, the changes can be made anywhere in thedistribution chain, including post transmission, because all of thesubsystems are integrated. If distribution for the media file hasalready occurred, an updated media file recipient sites remotelocations. This means that the content provider can change theavailability dates for an individual media file by logging onto the web,pulling up the data for that particular media file, changing theavailability dates, and the system will change the availability datesnot only within the system 100 itself, but also at all at the file'sdestinations. The system sends updated copies of the media file ifnecessary (over satellite, internet etc.) to perform the updates. Usersat the recipient sites can also change data surrounding that asset andthe same functions will apply. The system also has rules that allow thecontent providers to change certain data such as availability windowsfor the media file, but the recipient sites are allowed to change otherdata that is applicable to their specific systems, such as price. Theidentification of which entities are allowed to change which parameterfields can be stored as additional parameters in the media file itself.

This end-to-end visibility and system interoperability enables thesystem to affect any asset at any part of the distribution andmanagement chain. The claimed system is the only asset management systemwith this scope and combination of functionality.

One of the functions of the system 100 includes interactive programguide (IPG) metadata authoring. Some prior systems enable users toauthor IPG metadata, but only the claimed system 100 enables entities tosee exactly what that IPG metadata will look like at the eventualcontent recipient sites system immediately. In addition, the recipientsite can see what their IPG content looks like on their own system evenbefore the media file arrives. This is because the system takes thecontent provider's data and transforms it into recipient site-specificdata immediately upon ingestion in process blocks 150-154.

In one preferred embodiment, the system includes a multicast asset datapackaging subsystem and method, which is part of the packagedetermination process 152 of FIG. 1. With reference to FIG. 4, a singlemedia file 400 is used for distribution to two or more recipient sites.A first recipient site has first parameter requirements for processingthe media file 400, and a second recipient site has second parameterrequirements for processing the media file 400 that are different fromthe first parameter requirements. A first set of parameters 404 isincluded in the media file that meets the first parameter requirements.Further, a second set of parameters 408 is included in the media file400 that meets the second parameter requirements. In this regard, thefirst set of parameters 404 are for use during distribution to the firstrecipient site, and the second set of parameters 408 are for use duringdistribution to the second recipient site. Similarly, a third set ofparameters 412 is included in the file to meet the parameterrequirements of a third recipient site. Each of the first 404, second408 and third 412 sets of parameters are each identified by customeridentifiers 402, 406 and 410 respectively in the media file 400. Themedia file 400 includes a main body portion, wherein the actual mediafile content 450 is stored for eventual presentation in a recipient siteviewing system.

In this sense, the system 100 has the ability to superset (combinemultiple media files into one larger multicast file encompassing all thedata of the disparate media files) customized metadata for a recipientsite, as well as delivery and interface parameters into a single mediafile 400. To multicast means using a single transmission of a digitalfile to multiple reception points simultaneously. The claimed systemallows a multicast channel to be used in a more efficient manner, and tocentralize coordination of all remote recipient site requirements.Referring again to FIG. 1, the system also allows a single dockingstation 186 to offload files to a discrete list of destinations withouthaving to send the media file 400 to all of those destinations.

This structure of the media file 400 allows for use of a method ofdistribution whereby the same file is sent to all applicable receivingsites at the same time. In one embodiment, the media file 400 is a mediaor digital file for use in video playback, gaming or any other digitalfile. This file 400 is sent over a satellite link (190 in FIG. 1), theInternet, or the like, from the central system 100 to a local server. Itarrives on that server and is moved to a server for a receiving customerwhen a data control file arrives for the media file 400. The dataparameters and/or files required by each site are built into oneaggregate media file 400. Each section of that file 400 is targeted fora specific receive site, thereby keeping the localizing functionality,but requiring only one media file 400 to be sent over the multicast. Thereceiving site's equipment need know only the site's unique customeridentifier 402, 406 or 410 in order to extract the proper parameter dataset for its use.

In this since, the data within the media file 400 is customizable byrecipient site. For example, the price of the media file 400 or menulocation being used by the on-screen guide can be recipientsite-specific for each receiving recipient customer site. Further, themedia file 400 itself can appear to have multiple formats (XML, iTV, orany other widely accepted digital format), even though the specificformat of the file as used by a recipient site is part of the largeraggregate of the file 400, thereby enabling interaction with any formatof receiving site.

The media file 400 also contains, for each recipient site as part of theparameters 404, 408, 412, interface and delivery specifications uniqueto each recipient site. Examples include the specific IP address foreach recipient site's video server, the interface protocol required atthat site (ADI, Windows, FTP), the version of metadata file required atthat particular site (XML, iTV), and how the media file 400 should beprocessed after it is transferred from the central system 100 to thereceiving customer (e.g., delete immediately, stay on the system serverfor 24 hours etc.) as indicated by the parameters 404, 408, 412. Thisinformation tells the recipient sites how to react to, and act on, eachfile 400 it is receiving individually. This enables recipients to beunrestricted in their interactive behavior since the site itself nolonger requires parameters to be set within it, but rather can adoptasset-specific parameters each time a file 400 arrives because of thecontrol information contained within that file 400 by virtue of theparameters 404, 408, 412. This enables functions such as prioritizingfiles, wherein a media file 400 can be prioritized so that it jumpsahead in the sequence of transfer to the server it will reside on if itis a time-sensitive title. Or, the system enables a site to change thedelivery address of it's video on demand (VOD) server without having tostop the system 100 from offloading while it is reconfigured, since theparameter information is in each title as it arrives. This parameterinformation 404, 408, 412 is contained in the header of each data file400, and is populated by the system each time a file 400 is built fordistribution. This enables a receiving server to receive located at asite-specific control information on an file-by-file basis without thatinformation having to be stored in the recipients data file, which, insome cases would violate industry standards. The header is stripped offthe file before storage in the file to the recipient site's system.

This aggregation of the site-specific media data and delivery propertiesalso has the effect of making a change at the centralized assetmanagement system instantaneously applicable to any, or all, remotereceiving and distribution sites without having to configure files foreach site individually, or at the recipient site equipment itself.

In one embodiment, software is used to implement the asset datapackaging subsystem to create the media file 400. With reference back toFIG. 1, the steps performed by the software and the flow of data throughthe system components are illustrated. At process block 104 generalizedmetadata control file is ingested into the system for each media file400 that the system is expected to distribute to customers. This controlfile contains information specific to the media file 400 itself and, assuch, is not specific to any recipient customer needs. At process block150 this control file is transmitted by the system and checked againstexpected values that the media file 400 is allowed to have (e.g., ESPNwould not be allowed to enter into the system titles with an “X”rating), and the values are all normalized, that is, transformed intovalues the system can recognize and can key other functions off of. Atprocess block 152, the media file 400 is then run through a series oftransformations, one for every customer recipient site it will betransmitted to. The parameters are stored as site-specific data for eachof those customers in the media file 400. At process block 154, by wayof example, and not by way of limitation, these transformations includechanging any provider-specific information, such as a product type, intoa value desired by the recipient, applying the recipient site's correctprice and royalty information, applying the correct content category,and transforming the raw data itself into the type of file eachrecipient site requires as each of their servers may be built ondifferent operating systems.

When transmission occurs, the finalized information for each recipientsite is aggregated into one file 400 containing the data and applicablefile structure for every site to which it will be transmitted. The mediafile 400 is built as a contiguous series of these site-specific controlfiles, or sets of parameters 404, 408, 412, each in the recipient's ownsite-specific format, containing site-specific control information andcontrol data. At process block 158 this file 400 is subsequently queued,process block 156, and transmitted to each recipient. At each recipientsite, the file 400 is searched for the applicable site-specificsection(s). For each recipient site, the relevant section is extractedand stripped of any encompassing transmission-only control dataportions. This leaves only the relevant file information in the properformat for each specific site, ready to be processed.

In this process, the remote site devices at the recipient sites needonly know their assigned customer identifiers 402, 406, 410 in order tosearch the aggregate file for the recipient's relevant section and toextract the right parameters they will use to process the media file400. This allows the control data for every distributed device to bemodified and controlled at the centralized system, eliminating the needfor data to be kept on remote servers or for extensive configurationchanges to occur before transmission.

In one embodiment, the claimed invention is a system and method forautomated validation of a media file 400 for distribution. A media file400 having an asset type is received for distribution. It is validatedaccording to one or more requirements for the asset type. As a result ofthe validation process, one or more errors typically are produced. Theseerrors are corrected by applying a rules application to the media file.The media file 400 is then distributed.

With reference again to FIG. 1, in one embodiment, processing andvalidation includes polling (process block 104), parsing, validating,normalizing, rules application, error checking (process block 150),package determination (process block 152), site-specific datatransformation (process block 156), scheduling (process block 156),transmission-(process block 158), and finally, reconciliation andtracking of the media file 400. In one embodiment, the system 100receives the media files 400 by polling. Polling is the automatedreceipt and scanning of content into the system. The system constantlysignals all points on its network to determine if a media file has beeninput to any of them. If any media files 400 are found for input, thesystem downloads them, at process block 140.

Parsing is the automated determination of the file type for each mediafile 400 coming into the system, and the application of the properprocedures to that media file based on the file type. Validation is thedetermination of whether the incoming parameter data values and assettypes match the expected incoming parameter data values and asset typesbased on certain criteria such as the inputting party or file format.The system also checks for file-specific required constructs in theincoming data such as allowable lengths, time formats (24 hours vs. 12hours) and ID structures such as Cablelabs requirements of 20-digit IDvalues.

Normalization means taking the validated incoming data and transformingit into system-specific formats and values so the data can be acted uponfurther by the system 100. For example, date transformations occur forthe recipient sites to provide a baseline from which to transform themedia file 400.

A rules application processes the media file 400 through a complex rulesengine that is specific to the system 100 that enables the system 100 toset parameters and to format the media file 400 as necessary for furtherdistribution to receiving customers. As an example of this rulesapplication process, if a specific set of data contains specific valuesin certain fields, the accompanying file is priced at a certain level atsome recipient sites but not at others. If a media file 400 enters thesystem priced at $2.99 instead of, $3.99 from a particular movie studio,the system determines that the media file 400 is a “special” title forexample, a higher standard price such as and therefore changes the dataset it applies to the media file for the recipient sites. Some of thereceiving sites might elect to make any media file available thestandard price via their cable system, but others might decide to followthe lead of the studio and price the title at the special price.

In another example, a rule can be used to define that, if a certaincontent provider refuses to populate certain fields within the metadata,such as the content package description, the system uses other mandatoryfields, such as the provider name and price, to analyze the media file,for example, divine that the package must be a specific package from acertain provider. The system 100 then has the ability to run normalreceiving site transformations on the media file 400 for distribution.In summary, the rules engine applies intelligent rules to the data onceit has been validated and normalized as the first part of ingestion.

In the process of error checking, the system 100 determines whether theincoming media file 400 is free of errors and unexpected values, andtherefore whether the media file is ready to be approved for processing.

In the process of package determination, at process block 152 in FIG. 1,each media file 400 is assigned to a specific content package based onparameters in the media file's metadata. This assigned packagedetermines the distribution list for that media file 400.

The process of site-specific data transformation, a process block 154,transforms the media file 400 into data requested by each recipient sitein order to be applicable to their system-specific hardware, software,marketing wishes, and such.

With reference again to FIG. 1, in one embodiment, the claimed inventionis a system and method for automated determination of priority inprocessing a media file 400 for distribution to a recipient site. Amedia file 400 is received for distribution, at process block 140. Themedia file 400 is processed to produce data parameters for distribution,process block 150. As part of the processing step 150, a receivingstatus of the recipient site is checked. One or more of the dataparameters are changed according to the receiving status of therecipient site. For example, according to one embodiment, the dataparameters are changed according to a set or rules defined in a contractwith the recipient site. The media file 400 is then distributed to therecipient site according to the data parameters. Further, an interfaceis provided so as to allow the recipient site personnel to view statusinformation regarding distribution of the media file 400.

In one embodiment, the claimed invention is a system and method foroptimizing distribution of a media file 400 to a plurality of recipientsites. A receive status of a first recipient site is checked, therebyproducing a first status check result. A receive status of a secondrecipient site is checked, thereby producing a second status checkresult. Based on the first check result and the second check result, arules engine (process block 154 in FIG. 1) is applied to determine apriority for distribution to the first recipient site relative to thesecond recipient site. The media file 400 is then distributed to thefirst recipient site and the second recipient site according to thedetermined priority.

The system 100 is the first asset management system to prioritize,reorganize and intelligently manipulate a multicast pitch, which is asingle transmission of a media file 400 to multiple recipient sitessimultaneously. The system transmits media files 400 over a satellite orInternet protocol data network based on a schedule. The schedule isderived based on when the need of the media file 400 is to betransmitted to the recipient sites. This transmission is a multicasttransmission to a pre-determined combination of destinations, each withvarying ability to receive media files 400 based on the equipment statusat each recipient site. One unique feature of the system 100 is itsability to optimize distribution efficiency by accounting for thesestatus changes across its network and then reconciling those statuschanges with intelligent rules.

For example, if a recipient site in a distribution list for a specificmulticast transmission of a media file 400 is not functioning at thetime transmission is scheduled for that media file, the system 100applies intelligent rules to determine whether that transmissionrequires alteration. In one embodiment, one of those rules defines aminimum percentage of recipient sites that must have a “good” receivestatus before allowing transmission of the media file. The system'sautomated decision-making process takes into account whether anon-functional recipient site has not received the media file 400. Themedia file 400 can be retransmitted to that recipient site later.Alternatively, the system may delay the entire transmission for a setperiod of time. These decisions are based on rules derived fromindividual recipient sites (e.g., ability to receive files at thatmoment) and asset properties (e.g., time left before the specific assetis required to be transmitted to its customer base), as well as otherrelevant states (e.g., transmission speed, quality of the channel).

In one embodiment, another circumstance that causes a status change tothe media file 400 is the manual alteration of the transmissionschedule. The system 100 determines whether the change will have anundesired effect on another transmission or file status for a differentmedia file 400. Additionally, the system can predict when futuretransmission problems may occur, by calculating the performance ofnetwork components (e.g., bandwidth, speed, current transmission load),or anticipating upcoming requirements that may cause transmissionfailures. If a problem is predicted, the system adjusts the scheduleaccordingly.

With reference to FIG. 5, a transmission specific flow diagram is shownthat illustrates the data flow in performing prioritization andtransmission of the media files 400. Some of the components in FIG. 5are also shown in FIG. 1 with respect to the overall system. Thetransmission flow begins with the site-specific metadata transformer 500passing data to the queue scheduler 502. The queue scheduler 502 appliesscheduling rules to each incoming media file 400 based on rules locatedin both the package tables 504 and site tables 506. These rules includea date range for pitch, a potential time range, priority, channelrequirements, and such. Once the scheduler has the pitching parametersfor an individual file 400, it passes a reference to that asset to aqueue table, which will store it in a preliminary pitch order. Thistable is also viewable through the ARI 122 and PRI 120, wherein users560 can enter manual overrides, reprioritizations and re-pitches. Thistable is periodically scanned by the transmission controller 158. Thetransmission controller 158 uses an offline queue 510 to instruct amedia file manager 512 when to begin fetching media files from a mediafile data store 514, and to route them to a pitch drive. The controller158 then calls site-specific metadata tables 516 to aggregate metadatainto the media files using a media file creator module 520. When theparameters are properly packaged in the media file 400 for transmission,the final file distribution list is sent to the multicast transmissionsubsystem at process block 522.

The transmission subsystem is constantly sending and receiving statusdata across its network. While the system 100 is aggregating the network“health” information, it is applying what it finds to the list of mediafiles 400 it has in its distribution transmission queue 510. Each mediafile 400 to be distributed has site-specific parameters 404, 408, 412that need to be taken into account, such as the earliest or latest itcan be sent in order to meet its usability requirements.

In another example, if the system 100 determines that a certainpercentage of the receiving devices for a certain media file 400 are noton-line at the derived transmission time, the system applies thatknowledge against a rules system. The system then determines if themedia file 400 still has time to be delayed. It takes that informationand looks at the next media file 400 in the transmission queue. If thedistribution group of recipients for that media file is 100% online, itwill transmit a different media file 400 instead, saving the problemmedia file 400 until such time as its distribution group is back on linefor receiving. Alternatively, the file may need to be transmitted towhatever recipient in the distribution group is capable of capturing itdue to timing constraints. This intelligence, combined with the abilityto manually adjust the queue 156, gives the system the unique ability tomaximize the efficiency of its distribution bandwidth. There is a finiteamount of content that can be sent in any timeframe, and the ability totransmit only when the highest percentage of targeted recipient sitescan accept the media file 400 minimizes the need to retransmit files andmaximizes the finite bandwidth available to the system.

Referring now to FIG. 6, in another embodiment, the claimed invention isa system and method for providing connectivity in a media filedistribution system 100. The system includes a data store 720, a portionof which is for storing a media file 400 received from a contentprovider 702. A database in the data store 720 contains editableparameters for distribution of the recipient site. The PRI 120 providesan interface to the database and allows the content provider 702 to editthe site-specific parameters 404, 408, 412. The ARI 122 further allowsthe recipient site to edit the parameters. The distribution subsystem isconfigured for distributing the media file 400 according to thesite-specific parameters, 404, 408, 412. In one embodiment, thedistribution subsystem includes connections to the Internet 10 and/or toa satellite communications link 190.

The system allows customers at either usage end—i.e., receiving sitesproviders 702 and—the unique ability to view, edit and assign parameters404, 408 412 to a media files 400 in either their own or the other'ssystem. The claimed system 100 enables both content providers 702 andrecipient sites to gain information relevant to their product and makerelevant changes to their media files 400 within a single system. Thesystem is implemented by receiving edits and acting on the actual sourcemedia file 400 itself.

In one example, if a content provider 702 wants to assign an approvalfor a certain recipient site to acquire its programming, a contentprovider 702 can do so remotely through the PRI 120. If the recipientsite signs up for that content, which can also be done remotely throughthe ARI 122, the system 100 automatically requests parameters forassigning to the file for the recipient site (such as price, on-screenguide placement category, provider value), and it completes thetransaction without any manual intervention. The content providers 702supply information about the content, such as the parameter values withwhich each file will arrive (suggested price, suggested rating, andsuch). The receiving site can assign its desired site-specificparameters 404, 408 412 to the file 400 as well through the ARI 122. Thecontent provider 702 can display the parameter information and viewexactly how the content is being offered to that particular receivingsite's customers through the PRI 120.

Another example screen shot of the provider interface into the system100, the PRI 120, is shown in FIG. 7. In the screen shot of FIG. 7, theprovider is shown a list of available media packages for media files 400stored in the data store 720. Another example screen shot from the ARI122 is shown in FIG. 8. In this screen, the recipient customer can enterpricing information, package name information, a product description,transmission priority, and rating information for the package, which arecustomizations that can be viewed, edited, and/or validated by thecontent provider 702 in the ARI 122 in a similar screen. In this way,because both content providers and recipient sites have access to datawithin the system applicable to each other, they are able to view andchange the data for customization to their own systems. Contentproviders 702 are able to authorize a recipient site's ordering of apackage containing the content provider's media file 400, and the systemeliminates the need for manual assignment of that recipient site intothe transmission distribution list for the media file 400. Given that apreferred embodiment of the ARI 122 is web-based, and runs in a standardbrowser window, the recipient sites are able to view and edit themetadata associated with the media file 400 over the Internet, whichallows them to set the data without having to create their own separatesystem to do so.

In another feature of the system, when a content provider 702 submitscontent into the system (i.e., the content provider 702 sends a mediafile along with the controlling metadata file with its appropriateasset-specific information), the media file 400 is checked againstexpected properties and approved for ingestion into the system, asdescribed above. These properties and values are then, through a seriesof steps, modified to the individual requirements of each individualrecipient site wishing to receive that content, as described above.Those site-specific values are then assigned to that recipient sitewithin the central database in the data store 720, and displayed to thecustomer prior to transmission. The recipient site has the ability tochange any values prior to transmission through the ARI 122.

In one embodiment, the site-specific parameters 404, 408, 412 followcertain expected criteria and value ranges. Automated assignment of atleast some of those values is triggered by the expected input values andassignment of others is triggered by the expected outbound values forthe site-specific parameters 404, 408, 412 of the media file 400. Thesystem 100 allows the recipient sites to see the inbound media files 400in order to transform it from 100 any way they see fit. The system alsoallows the inputting customers, i.e., the content providers 702, to seethe results of their data being transformed by the recipient sites.Since both sets of data reside within a single data store 720, it ispossible to display both sets to users at either end of the distributionchain. This gives both content providers 702 and recipient sites eachmore visibility into what the other is doing with their half of thedistribution chain. It also gives them more control. A content provider702 can assign contract values or on-screen display values to aparticular video asset in a media file and restrict the recipient sitesto which the media file is made available from changing those values.The content providers can then see the end result by looking at theactual data within the system. They can also authorize or de-authorizespecific recipient sites within the system for receiving an media file400 in the first place, simply by logging into the system and assigningparameters to their content, such as which recipients can or cannotreceive particular media files 400.

Recipient sites can see the incoming values the content provider 702makes available with the content providers assets and then the recipientsites can set up transformations to those assets prior to or aftertransmission to its own equipment. The recipient sites can stop specificmedia files from coming to their system if the media files for thoseassets contain certain data types (such as those with an “X” rating, andthe like). A recipient site can request certain media files if they havenot already been authorized for them, and they can track the inputdelivery timeframes to see whether a media file will be transmitted asexpected. This ability to act on the actual data inputted by the contentproviders means the system is the only place participating contentproviders and recipient sites need to view, enter and edit the parameterdata, and it gives them the ability to do so at any point in time alongthe media file 400 asset lifecycle.

In another embodiment, the claimed invention is a system and method forproviding interactive program guide entry for a media file 400. Adistribution hub (data store 720 in FIG. 6) stores a media file 400received from a content provider 702 for distribution to a recipientsite. An interface to the distribution hub (ARI 122) allows editing ofprogram guide data for the media file. The interface stores the programguide data as site-specific parameters 404, 408, 412 to the media file400. The interface further allows the content provider to view theprogram guide data for the media file 400. In one embodiment, theinterface further allows the content provider 702, through the PRI 120,to edit the program guide data, and to set parameters regarding editingof the program guide data by the recipient.

As discussed above with respect to FIGS. 2, 3, 7 and 8, the system hasweb-browser based graphical user interface (GUI) functionality. Furtherbuilt in to this GUI functionality is the ability to allow entities(i.e., either content providers or recipient sites) to easily manipulatetheir interactive program guide (IPG), or on-screen TV set navigationguide. The interface allows the recipient to structure and map incomingmedia files 400 to their interface.

For example, in one embodiment, when a viewer on a recipient site'snetwork enters a video-on-demand (VOD) section of the recipient site'stelevision IPG, there is a hierarchical menu through which to navigatevia the remote control organizing all of the video files by category.The recipient site (e.g., cable company or telephone company.) mapsevery asset it receives on its video-on-demand VOD servers to an IPGmenu location prior to the asset's arrival within its system, and thedata files accompanying each digital file preferably contain thisinformation. The claimed system graphically links the content provider702 and recipient site's IPG. This enables the recipient site to do themanually intensive mapping process on an easily manipulated graphic userinterface, available in the ARI 122. Through the same interface, thesystem also provides the ability to link incoming content providers'menu data to IPG menu.

A media file 400 sent by the system to a recipient has a field in thesite-specific parameter 404, which carries the hierarchical menu datathat defines the destination on the recipient site's IPG. This IPG mightbe displayed, for example, on a television, set-top box, web page, phoneor any other electronic system. The media files 400 being input intosystem by the content provider 702 contain a generalized value in thisfield, used more as a characteristic of the asset contained in the mediafile than an expected display value. This generalized value istransformed into a specific value for each recipient site to use inprocessing the media file 400 which, in one embodiment, comprises takingany expected potential incoming menu value and performing asite-specific transformation (per recipient site) on it, based onpreviously entered information about the recipient site's IPG. Currentsystems do this by taking a text menu string of incoming data andtransforming it into an outgoing text string. This requires repeatedentry (manual or automated depending on the systems) of the strings pereach incoming type and for each recipient site. This is no longerrequired when using the claimed system.

With reference to FIGS. 9 and 10, example embodiments of IPG editingscreens that can be presented from the ARI 122 are shown. A graphicalmenu builder provides easy IPG entry into the IPG parameters 404 of themedia file 400. Recipient sites have the ability to enter, map, move,replace, delete and populate menu locations through this easily usableinteractive GUI. FIG. 10 illustrates the screen shown after selection ofthe “Outdoor Life Network” entry in the screen show in FIG. 9.

Referring back to FIG. 1, in another embodiment, the claimed inventionis a system and method for providing a multi-port catcher 146. Thesystem includes a computer 108, a data store 514 (or 720 in FIG. 6), anda network connection 106 for connecting the computer to a network. Inone aspect of this embodiment, a partition application is executed onthe computer 146 to partition the computer into multiple partitions. Acatcher application 146 (a remote receiving computer that receives andrebuilds the transmitted files) executes in each partition. Each catcherapplication 146 is capable of receiving a separate media file 400 overthe network connection, simultaneously. Each media file 400 is stored inthe data store 514. The system may use a plurality of catcherapplications 146, wherein, for example, a first partition executes afirst catcher application 146, and a second partition executes a secondcatcher application 146. Therefore, the first catcher application 146can use a different protocol than the second catcher application 146. Inthis sense, the partition application is configured to divide processingof a processor of the computer into virtual computers, such that each ofthe media files 400 is received by a partition executing on one of thevirtual computers.

In one embodiment, one of the partitions is configured as a contentprovider itself, such that one or more of the media files 400 can beprovided internally from the data store into the catcher 146 withoutusing a separate computer 108 to provide the one or more media files 400to the catcher 146. In this or other embodiments, one of the partitionsis further configured as a gateway computer to provide gatewayprocessing, such as SMTP 144, FTP 148, and/or encoding/offloadingfunctions 149, for each of the other partitions.

In one embodiment, the catcher 146 is implemented as a file receptionserver 800 located at a recipient customer location or cable head end,executing catcher partitions 146 a and 146 b. The system 100 allows onecatcher 146 to receive multiple asset reception streams/transmissionsfrom multiple distributors, all organized and reported on from thecentralized database in the data store 720.

In current digital video distribution networks, a “catcher” has onereception path that validates and offloads the received files onto thedestination server for the received files (the recipient sitesequipment). The partitions 146 a and 146 b on the catcher 146 enablemultiple, unique, exclusive reception paths for multiple transmissionsystems to deliver media files 400 to it. The media files 400 aretreated uniquely based on their origination point, but the data isentered into the central data store 720 (by way of the catcher sendingit back to the central system), giving one point of reference to therecipient site. This is unique because previously, any recipient sitethat required content delivered from multiple sources required multiplecatchers (one per source), and a separate physical gateway to manage themultiple offloads into one destination video server. The catcher 146 ofthe presently claimed system is capable of not only receiving multipleinbound transmissions from different sources on the same hardwareplatform, but it is also capable of performing the gateway trafficmanagement function, thereby consolidating previously disparatefunctions into one. The catcher 146 also includes the ability to ingesta local media file 400 without the need for it to be transmitted from aremote destination.

In order for the catcher to perform these functions, a softwareapplication executes internally in the computer to partition a singlecomputer into multiple receiving points 146 a and 146 b. Each partitionhas the ability to execute industry standard file-movement protocolswithin the same computer 108. This allows the catcher 146 to receivemultiple streams from different satellite receivers, from locallyintroduced content over an IP network, or from another catcher 147physically attached to the catcher 146. The media files 400 areoffloaded from the catcher 146 through one point, eliminating the needfor the recipient site to put a separate gateway on the network. Themedia files 400 are aggregated into the centralized data store 720,thereby allowing the recipient site to perform data manipulation andreporting from one system regardless of the origination point of thetransmission.

In one embodiment, each catcher 146 a, 146 b is implemented in software.This software scans both internal folders in catcher 146 and externalfolders on the network to which the catcher 146 is attached. These filesare brought into a staging area/folder in the catcher 146. The metadataassociated with those files (which arrives with the files) is sent backthrough the Internet to the centralized data store 720. With referenceback to FIG. 1, the metadata is then scanned for compliance, processblock 150 in FIG. 1, which includes analyzing the media file 400 todetermine the identity of the content provider 702, and normalizing thesite specific parameters 404, 408, 412 into a standard set of values therecipient site has requested. The parameters 404, 408, 412 are storedinto the multicast structure, and the data is re-sent to the catcher146. The system then moves the submitted digital file 400 off of thecentral data store 720 onto the recipient site's video server. Should amedia file 400 that is not allowed or expected arrive on the systemcatcher 146 from an outside source, the file is quarantined on thecatcher 146 and not moved to the central data store 720.

The centralization in the system allows the recipient site to view allof its digital file parameter and media data in one central place, andalso allows it to use that same system to update media files 400 acrossthe entire set of sites it owns from one place, regardless of whether ornot those media files originated from the central data store 720.

In another embodiment, the claimed invention is a system and method foradministrating a contract for distribution of a media file 400. A mediafile 400 is received from a content provider 702, after which, contractparameter data is entered into the media file 400 according to acontract between the content provider and a recipient site. Metadata iscalculated for the media file 400 based on the contract parameter data,which is stored in the site-specific parameters 404, 408, 412 of themedia file 400. The media file 400 is then distributed to the recipientsite. In one embodiment, by way of example, and not by limitation, thesite-specific parameters 404, 408, 412 include price limitations for theprice that the recipient site can charge viewers for viewing of themedia file 400. As another example, and not by limitation, the contractparameter data 404, 408, 412 include time limitations defininglimitations regarding a time that the recipient site can present themedia file 400.

The contract management system enables functions for the administrationof a contract (between any or all of content providers, distributors,recipient sites, studios or other applicable parties) with respect to amedia file 400. By way of example, and not by limitation, thesefunctions include a contract to derive N number of unique, site-specificfinancial parameters for use in multiple places within the system, andthe unique use of contract entity building blocks (such as provider,receiver or distributor element) to determine financial fulfillment andprocessing.

With reference to FIG. 11, in one embodiment, at step 1100, one entityhas the option of managing contracts in one of two different ways,either by using package properties or by using site properties of thesite-specific parameters 404, 408, 412. Next, at step 1102, a choice ispresented to the user for selecting the level not selected in step 1100(i.e., if the option for package properties was selected, the siteproperties are selected). With respect to package properties, the usercan view the hierarchy of the package recipient sites sorted by MSO, andthe recipient sites they each own. The recipient site of contentprovider 702 can then select any of these groups (the entire set ofpackage recipient sites or any number of MSO's and/or sites) forcontract creation or editing. The level to be applied is selected, whichincludes by package, MSO, or recipient site, at step 1104. If theselected level doesn't have a contract already created, step 1106, thesystem 100 offers the opportunity to create the contract or contracts,at step 1108. If a recipient site group is selected and applied in bulkby using MSO or package editing, and some of the recipient sites do notyet have a site contract, then one will be created for those that do notalready have one, at step 1110. Then all recipient sites under thecontract parameters are updated to reflect the choice of contract to usefor the sites, at step 1112. Otherwise, if the user chose not to createa contract when there was no contract in place for a package, MSO orrecipient site, then those sites that are left without contracts aremarked with an error condition in the system, step at 1114.

In one embodiment, if additional recipient sites are added to thepackage, they do not automatically inherit the contract level choicemade in bulk earlier by selecting MSO or Package for contract creationor editing.

In one example using the system, the user can view all packages thatexist, and the packages to which a recipient site belongs. If a newpackage for a recipient site is selected, the user is taken to acontract application level selection screen, where the user can chosecontract editing by package, MSO, or recipient site. The user can alsoselect a package for which the recipient site is already a member, andupdate contract parameters. As explained above, if the newly chosenlevel doesn't yet have a contract created, the user is offered thechoice to create the contract.

In one embodiment, after contract creation, parameter data reflectingthe contract is stored in the package tables of FIG. 1. When a mediafile 400 that is subject to the a contract is processed through thesystem 100, during the package determination process 152, the packagetables are read and the appropriate parameters are inserted into thesite specific parameters 404, 408, 412 into the media file 400.

With reference to FIG. 12, when choosing a contract level (through siteproperties) the system 100 shows all three potential levels, the packagelevel 1200, the MSO level 1202, and the recipient site level 1204,whether or not a contract is available on those levels. When thecontract level is selected, the system displays an indicator showingwhether a contract exists at that level. If a contract is created by thesystem, initially, a contract template 1206 is used to form thecontract, after which, the contract is modifiable.

Although the invention has been described in language specific tocomputer structural features, methodological acts, and by computerreadable media, it is to be understood that the invention defined in theappended claims is not necessarily limited to the specific structures,acts, or media described. Therefore, the specific structural features,acts and mediums are disclosed as exemplary embodiments implementing theclaimed invention.

Furthermore, the various embodiments described above are provided by wayof illustration only and should not be construed to limit the invention.Those skilled in the art will readily recognize various modificationsand changes that may be made to the claimed invention without followingthe example embodiments and applications illustrated and describedherein, and without departing from the true spirit and scope of theclaimed invention, which is set forth in the following claims.

1. (canceled)
 2. A method for providing an interactive program guideentry for a media file, the method comprising; receiving a media filevia a communication network from a content provider for distribution toa plurality of recipient sites, wherein the media file includesinteractive program guide (IPG) data; storing the received media file ina database, wherein the stored media file includes a plurality ofsite-specific parameters, each of the plurality of site-specificparameters being specific to a respective one of the plurality ofrecipient sites; storing the received IPG data in each of the pluralityof site-specific parameters of the stored media file; storing arespective data structure for the IPG data in each of the plurality ofrecipient sites; distributing the stored media file to the plurality ofrecipient sites; mapping the IPG data to a respective data structure ata respective recipient site, according to a respective site-specificparameter for said respective recipient site; and linking an incomingIPG data from the content provider to each respective data structure ineach recipient site, according to respective site-specific parameters.3. The method of claim 2, further comprising allowing the contentprovider to set parameters regarding editing of the IPG data by arespective recipient site.
 4. The method of claim 2, further comprisingallowing the content provider to edit the stored IPG data.
 5. The methodof claim 2, wherein the IPG data includes menu data.
 6. The method ofclaim 2, further comprising allowing a respective recipient site to edita respective stored IPG data of said respective recipient site.
 7. Themethod of claim 2, wherein the received media file further includes afield in the site-specific parameters for defining a destination on therespective IPG data structure.
 8. The method of claim 7, wherein thefield includes a generalized value when received from the contentprovider, the method further comprising transforming the generalizedvalue into a specific value for each recipient site after the media fileis received from the content provider.
 9. The method of claim 2, whereinthe recipient sites are one or more of the group consisting of a cablecompany and a telephone company.
 10. The method of claim 2, furthercomprising transmitting the media file including said respective IPGdata by each of the recipient sites to a respective plurality ofviewers.
 11. The method of claim 2, wherein said communication networkis the Internet.
 12. The method of claim 2, wherein said communicationnetwork is a satellite link.
 13. The method of claim 2, wherein saidmedia file is for use in a video play back.
 14. The method of claim 2,wherein said media file is for use in gaming.